COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂04-AUG-76  0908	FTP:Guy L. Steele, Jr.  (GLS @ MIT-AI)	Hiya back  
Date: 4 AUG 1976 1208-EDT
From: Guy L. Steele, Jr.  (GLS @ MIT-AI)
Subject: Hiya back
To: jra at SU-AI
CC: GLS at MIT-AI

[a] Congratulations on upcoming nuptials.
[b] I have been plowing through chapter six, but
    have been very busy lately with MIT projects.
    I have not forgotten you, however.
    One problem is that I got very frustrated halfway
    through the chapter, because of the great profusion
    of confusion, and it took a long time to get
    up the courage to continue.  (Primarily, I was
    somewhat annoyed by the radical changes you claimed
    were necessary to EVAL to get in shallow binding,
    whereas if you had coded the deep binding more
    modularly earlier, the changes would be much less drastic.)
Oh well, I'll look forward to seeing new version,
and will passs on my comments on chapter six in any
case when I finish it.  Cheers.
				- Guy
-------

∂10-SEP-76  1253	FTP:Guy L. Steele, Jr.  (GLS @ MIT-AI)  
Date: 10 SEP 1976 1552-EST
From: Guy L. Steele, Jr.  (GLS @ MIT-AI)
To: jra at SU-AI
CC: GLS at MIT-AI

Ooops, I meant to send off chapter 6 some time ago.
Okay, fair trade.  It may take a few days to get all together...
-------

∂03-Dec-76  2304	FTP:GLS at MIT-MC (Guy L. Steele, Jr. ) 
Date: 4 DEC 1976 0202-EST
Sender: GLS at MIT-MC
From: GLS at MIT-MC (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-MC
Message-ID: <[MIT-MC].17919>

The following mail got routed to some weird destination
at MIT-MC, so I am mailing a copy in case it DIDN't get
to SAIL.

GJS@MIT-AI 12/02/76 20:48:49
To: JOHN at MIT-AI
McCarthy 
It's on its way.

∨
GLS@MIT-AI 11/26/76 00:44:20 Re:  MONEY, MONEY, MONEY -- also turkey, turkey, turkey
To: GLS at MIT-AI, JOHN at MIT-AI
Allen 
much gratitude for the money!
also, recall that "trce, trce, trce" is the best way
to exchange two bits in a pdp-10 ac (see "hakmem"),
and so is appropriate for today.
also great frabjosity today because boston latin
won the latin english game 11-6.
(one day a year i turn into a rabid football fan for
the morning.)


∨
GLS@MIT-AI 11/22/76 12:30:29 Re:  lisp 
To: JOHN at MIT-AI
CC: GLS at MIT-AI
Allen 
One other reference you might want to look at if you haven't
already is:
	Fateman, R.J.  "Reply to an Editorial."  SIGSAM Bulletin 25, pp. 9-11.

I have tried to read the new chapters 2 and 3, but may not have too
much time in immediate future.  I'll do what I can.

Presumably what Moses meant was that such details as actually exist
are okay for the public to have.  Unfortunately few actual documents
have been produced.  That situation should improve in next 6 months.
Meanwhile, I may be able to answer any specific questions
if you need them for the book.

I would be very interested to see Cartwright's work -- I haven't
heard of it.
			-- Cheers, Guy

∨

∂04-Dec-76  1321	FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) 
Date: 4 DEC 1976 1620-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].34717>

I assume you meant "hunks".  They are essentially a crock,
which I am not entirely proud of, to stave off the address space
crunch in the PDP-10 implementation of MacLISP.
They are essentially short vectors of fixed size; they have
no header as an array does (which occupies 8 words or so).
People generally use them to create small heterogeneous data
structures of more than two components.  They take half the space of
a list, since no cdr pointers are needed.  They will not
exist on the LISP machine implementation, as the cdr-code
notion yields exactly the same savings, more or less.
Hunks also provide slightly faster access than a list does, but
that consideration is secondary to that of space.


∂27-Dec-76  1247	FTP: host AI	xxx    
Date: 27 DEC 1976 1547-EST
Sender: gls at MIT-AI
Sent-by: DVM at MIT-AI
Subject: xxx
To: jra at SU-AI
CC: gls at MIT-MC
Message-ID: <[MIT-AI].42656>

No word from McGraw-Hill yet; my thumbs are now getting
quite long.  My BS [sic] Thesis is indeed available from
Harvard as a Technical Report.  I eagerly await the
publication of the book.  Merry Christmas, Happy Chanukah,
Thrilling New Year, usw.

∂06-Nov-77  1159	FTP:GLS at MIT-AI (Guy L. Steele, Jr.) 	grumble, grumble    
Date: 6 NOV 1977 1458-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: grumble, grumble
To: JRA at SU-AI
CC: GLS at MIT-AI

I am told that PASCAL is not as pretty in actuality as people
like to believe; the language definition itself is full of glitches.
(What I am about to say is 1.5-hand information, so double-check
before quoting me.)  I am told that the definition explicitly
allows sets to have an implementation-dependent maximum size,
typically 16 or 32.  This is evidently so that one can use
single-word boolean instructions to do set operations (e.g. AND
for intersect), and the definers/implementors didn't want to be
bothered with multiple-word operations.  Now one of the most
natural sets to deal with, especially when writing the parser
for the compiler, is the character set -- but this set is too
large (at least 64) to represent in most implementations!
I believe that strings also have a maximum length -- but identifiers
do not!  This makes it very hard to represent identifiers
as strings in a compiler.  I think that in practice the compilers
cheat and limit identifier length.
It may be that in fact there are no dynamically allocatable data
structures in PASCAL at all.  You might check out the definition
of EUCLID in SIGPLAN Notices within the past year or two.
All in all, PASCAL is another ALGOL with a couple of good new ideas
(like sets of symbolic constants), but it's not the ultimate answer.

I am busily trying to turn my thesis into a technical report.
I have souped up and cleaned up the compiler a bit more, and will
include it, annotated, as an appendix.  Plans are afoot to
experimentally provide lexical scoping on the LISP Machine
and build a RABBIT-like compiler for it.  The LISP Machine
otherwise proceeds apace.  It has successfully run the Woods LUNAR
program and a good portion of MACSYMA.  Tests on LUNAR show that
it is about three times as fast as MacLISP on a KA10, which was
in turn five times faster than in InterLISP.  The LISP Machine
has a working compiler and real-time editor.  One can use the
editor as the front end to the read-eval-print loop, and the "print"
can go back into the edit buffer in case you want to edit that.
One can have a different editor buffer for each function, and jump
back and forth; there are three commands to exit the editor
(exit, exit and eval, exit and compile).  Debugging software is
being developed.  Currently undone are bignums, floating point,
interrupts, and the garbage collector.  The GC will use Baker's
real-time algorithm (there is never a dead pause, but it is not
asynchronous either; every CONS does a little bit of GC).
The CHAOSNET interface is semi-alive, and the software for it is
being written and tested.  The file computer system is being planned.
Eventually there will be a large number of LISp Machines,
all hooked together via CHAOSNET (an Ethernet) to one or more file
computers (which may or may not also be LISP Machines) and the PDP-10s.
The basic LISP Machine idea seems to be working out.  The editor is
quite fast, "despite" being written entirely in LISP.
The second prototype is being built; plans call for producing one
production machine a month starting in January.

As for other work, I'm sort of floating about thinking about
writing a Ph.D. thesis proposal.  My latest papers were in
SIGPLAN Notices Aug 77 and Proc. ACM 77.

Glad to hear the book is finally about to happen.  I can't wait to
see the final product.  Have fun out in California, and don't
let the PASCAL types get you down.  (You might point out to them
the size of a typical PASCAL compiler compared to a LISP system;
there is a paper in the just-come-out MICRO-10 (SIGMICRO Bulletin)
proceedings about a microcoded LISP machine which makes comparisons
to some other languages -- I think it's by Griss, but there are a
couple of papers of that variety.)
			-- Guy